home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 4838 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.5 KB
  1. Path: peer-news.britain.eu.net!uknet!str-ccsun!not-for-mail
  2. From: nbc@vulture.dmem.strath.ac.uk (Neil Brendan Clark)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Acorn RiscPC --- a thought?
  5. Date: 12 Feb 1996 19:08:49 -0000
  6. Organization: University of Strathclyde
  7. Message-ID: <4fo381$c0t@vulture.dmem.strath.ac.uk>
  8. References: <1996Feb5.164323.465@rmcs.cranfield.ac.uk> <1996Feb8.124744.14853@leeds.ac.uk> <4fdglm$b8s@vulture.dmem.strath.ac.uk> <1996Feb12.152844.28437@leeds.ac.uk>
  9. NNTP-Posting-Host: vulture.dmem.strath.ac.uk
  10.  
  11. J M Oldak <csxjmo@scs.leeds.ac.uk> wrote:
  12. >Neil Brendan Clark writes:
  13. >
  14. >On the plus side - Co-operative multitasking means that the programmer has to
  15. >be aware of the efficiency of the program. 
  16.  
  17. This is a plus point? With a proper MT system, the programmer does not have
  18. to be aware that he is sharing the CPU with any other processes, at least
  19. in a simple sense. The *one* benefit I can think of concerning coop MT
  20. is that concurrency control becomes easier in some situations - effectively
  21. because there is none ;-)
  22.  
  23. >This means that the program can use little or no processor time if it 
  24. >isn't doing much. For example, a desktop clock only has to bother the 
  25. >OS every second, the rest of the time it can use no time at all. 
  26.  
  27. This is not a feature unique to co-op MT! Do you really think that on 
  28. proper MT systems *every* task is busy waiting? On my UNIX box at work,
  29. there are currently 67 processes. If what you state was the case, the
  30. machine would be utterly swamped. No, within all proper MT systems, there
  31. are various methods for setting up timing and so on. In the case of your
  32. desktop clock, a simple way would be to use UNIX sleep() or AmigaDOS Delay().
  33. These calls simply place the task onto another queue of "sleeping" processes,
  34. whereas the ones wanting to run are placed on a "runnable" queue, until
  35. their time is up. More sophisticated mechanisms also exist, such as the
  36. UNIX alarm() call. Of course, there is a small overhead to pay for this,
  37. but it is *very very* small.
  38.  
  39. >Furthermore, there are times when single tasking something is
  40. >an advantage. If you are, say, viewing an MPEG (possibly a bad example...),
  41. >why not let the thing single task? 
  42.  
  43. Again, this can be arranged. If you set the MPEG task to a high priority,
  44. it will get all the CPU time it needs at the expense of other tasks, giving
  45. the effect (more or less) of single tasking. You have the choice!
  46.  
  47. >There are times when you want as fast a
  48. >response as possible...
  49.  
  50. Again, set up your process to have a high priority and your wish comes true.
  51. In fact, I have generally found cooperative MT systems to have dismal
  52. interactive response times; you in fact cannot guarantee a fast response
  53. at all.
  54.  
  55. >No, it just let's all tasks that want processor time have it. Win 3.1 (and Win
  56. >95 with old apps) does not.
  57.  
  58. It must have some CPU arbitration mechanisms then?
  59.  
  60. >gee, thanks!
  61.  
  62. Oh, that's OK! ;-)
  63.  
  64. >During that 0.8 seconds - does the machine multitask?
  65.  
  66. Yes.
  67.  
  68. >If so - why?
  69.  
  70. Many reasons. The machine is networked, so certain housekeeping tasks must
  71. go on in the background. The machine is also an NFS server and the host for
  72. an X Terminal in the lab (i.e. it runs processes which are displayed on another
  73. machine, like a GUI terminal). There is a dumb terminal also dangling off it,
  74. and there may well be other users logged on from various sites around the 
  75. campus. In addition to this, I am running an http daemon, and sendmail also
  76. kicks about strutting its funky stuff now and then. It wouldn't do for
  77. everything to stop when I was decompressing a JPEG! 
  78.  
  79. Another good reason is that I had to convert many tiff files to JPEGs recently;
  80. a small shell script running at low priority in the background while I did
  81. other things was a most useful solution - why lock the machine up?????
  82.  
  83. >You could be using them all!
  84.  
  85. OK, in theory you could, but in reality it is still not heavily loading
  86. the machine - you are still doing things interactively.
  87.  
  88. >You could be copying/compressing files etc in the command shell, 
  89.  
  90. Disk I/O is slow, leaving spare CPU cycles.
  91.  
  92. >while doing a drag & drop OLE from your Vector drawing (or JPEG decompressor) 
  93. >into the DTP program...
  94.  
  95. Again this is pretty interactive, and the CPU will be idle for most of the time.
  96.  
  97. >|> Hopefully with proper multitasking. I think part of the problem with people
  98. >|> who claim that you don't need pre-emptive MT is that they have never really
  99. >|> used it before. Once you have used such a system, there is no going back. 
  100. >
  101. >Untrue!
  102. >
  103. >I use SGI's in the university with X windows. They have more power than my Risc
  104. >PC, but in general use they run slower, because background tasks are taking
  105. >time from my foreground ones. 
  106.  
  107. Rubbish. You are comparing apples and oranges here. *If* there are background
  108. tasks running (presumably created by other people?) then they will have to
  109. busy wait to eat CPU time. If they are interactive backgroud processes, they
  110. will use very little CPU. You will have to try very hard to see any difference
  111. in this case. If people are ruuning CPU intensive tasks in the background,
  112. they really should "nice" them to give interactive users more CPU time. It
  113. is possible to set up the system to do this automatically. In any case,
  114. a busy tasks priority decays with time, whereas a task that voluntarily gives
  115. up the CPU instead of having to be repeatedly forced off it retains a high
  116. priority. You seem to have the notion that every task eats CPU all the
  117. time; this is not the case. In fact, most tasks are idle most of the time.
  118. To illustrate, here is some output from my UNIX box;
  119.  
  120. USER       PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED       TIME COMMAND
  121. nbc      12301  0.0  1.6   456  220  p2  R+    7:03PM    0:00.01 ps -ux
  122. nbc      12103  0.0  3.7   376  528  ??  S     6:02PM    0:05.00 fvwm -s
  123. nbc      12114  0.0  0.2   568   28  p3  Is    6:02PM    0:00.36 -csh (tcsh)
  124. nbc      12115  0.0  3.9   572  552  p2  Ss    6:02PM    0:00.51 -csh (tcsh)
  125. nbc      12130  0.0  0.7  2572   88  p3  I+    6:02PM    0:04.15 trn
  126. nbc      12168  0.0  1.5   260  204  ??  I     6:05PM    0:00.28 /usr/X11R6/lib
  127. nbc      12169  0.0  0.0   464    0  ??  IW    6:05PM    0:00.02 /bin/sh -c xcl
  128. nbc      12170  0.0  1.9   252  264  ??  I     6:05PM    0:00.21 xclock -bg #90
  129.  
  130. Note the %CPU column?
  131.  
  132. >Admittedly, ithas to be pre-emptive for it to be
  133. >a multi-access system, but I'm talking about what it's like sitting at one,
  134. >disregarding other people...
  135.  
  136. Perhaps you just have a heavily loaded system?
  137.  
  138. -- 
  139. "I have trouble imagining death at that income level" - White Noise, D.Delillo
  140.  
  141.                  Neil Clark, Transparent Telepresence Group
  142.                    http://telepresence.dmem.strath.ac.uk
  143.